Often, transferring data in phones can be very cumbersome. In particular, modern phones may hold multiple gigabytes of data comprising pictures and other graphical representations, address records, emails, documents, and other data. A lot of overhead going through the applications creates a data bottleneck for service stations and other stores that offer such data transfer services.
FIG. 1 shows two typical telephone/PDA device data transfer stations. In FIG. 1A, transfer station 100 has a phone data transfer machine (PDTM) 110, typically a PC with USB and Bluetooth connectivity running phone data transfer applications such as PC Suite, PC Tools and other phonebook transfer applications, which typically may connect to two handsets: originating handset 101 and a receiving handset 102. Said connections are typically made via USB cables 103 or custom cables 104. Each phone has its own operating system with software 101a and 102a, respectively, and data sets 101b1-n and 102b1-n, respectively. This data may contain a variety of information, including, but not limited to, address book data, phone numbers, email addresses, pictures, video clips, and other types of data that may be used by cell phones and their applications. In some cases even the applications installed on the phone and/or the application data may be transferable. Typically, machine 110 would have its own operating system 110a, which has multiple programs 110b. Often, machine 110 with operating system 110a and programs 110b is actually a custom, dedicated PC, and as such it has to contain drivers or DLLs 110c for all the phones to which it may be connected. As a result of having a large library of DLLs (or drivers, used interchangeably here) almost any data transfers between two different phones can work. The machine can, by using the DLLs, communicate and download the data objects (each item typically comes down as one or more data objects from the phone), which are then stored in machine 110 temporarily and eventually sent on to the other phone, as its data objects, using the matching DLL. Each of these devices has a CPU and memory, both volatile and nonvolatile, and thus each forms a small, distinct computing device.
FIG. 1b shows another type of known data transfer station 120. Copy machine 121 has only one connector. It is first plugged into the originating machine 101, using connection 105, via which connection the data is transferred into machine 121. Then the receiving device 102 is connected by a cable connection 106 (dotted) in a second step, and that connection is used to transfer the data from machine 121 to phone 102. Again, these devices have operating systems, programs, and DLLs, as described above in the discussion of FIG. 1A.
A large cost is inflicted on cellular network operators by the user practice of returning devices for repair or exchange that are not actually defective. There are several reasons for this problem: some operating intermittencies may not be caught during in store testing of a defective device, or the problem may be caused by peripheral devices that are not returned with the supposedly faulty phone. A large portion of the problem may be attributed to user configuration errors, network configuration errors, or user software add-ons that are installable in the phone but may not be completely compatible with the particular phone set up and its particular network. Only a small fraction of returns are due to actual failure of the hardware. However, efficient and expedient repair of handsets is very important, because the cost of each handset repair affects the final profitability of an operator. One of the most important aspects of handset repair is efficiently achieving a specific level of program and data sets in a repaired handset.
In some cases, more thorough diagnostics of devices with problems are needed than the diagnostics that are available currently. These diagnostics should not merely rely on internal functional diagnostics, but they should also include hardware configuration diagnostics, program configuration diagnostics, and network configuration diagnostics; and they should also look for other factors, including but not limited to program compatibility issues.
Often, the exchange of data objects between different phones is desired or required. Some phones do not support such a feature; other phones have a very limited ability in this regard. For example, such phones may allow exchange of an object such as a business card, but do not support exchange of photos, videos or other larger graphic images.
In some cases wired telephone connections may be difficult or impossible due to defective connectors, unavailable infrastructure, etc.
Some telephone devices are notoriously difficult to access with an in-store diagnostic device, be it wirelessly or via wired connection. In the context of universal serial bus (USB) devices, the manufacturers are supposed to use vendor ID (VID) and product ID (PID) numbers to distinctly identify every product.
These VID/PID numbers are often also used in other connectivity schemes, including but not limited to Bluetooth (BT), local area network (LAN) and over the Internet. These access problems occur due to various legitimate or not-so-legitimate reasons, and more frequently, device manufacturers either re-use the same VID/PID numbers for different devices to save money on registration fees, or in other cases, a fly-by-night garage-style manufacturer clandestinely produces a series of few hundred or a few thousand devices and then closes up shop. This is often because such phones infringe copyrights or other intellectual property, pretending to be brand-name manufacturers' phones, but using different components, such as chips. Despite these problems, it is sometimes desirable for an operator, such as, for example, an independent store operator, to provide service nevertheless, doing so to maintain good customer relations, rather than to rebuff or annoy a customer.
In many cases, it is desirable to back up the data on a mobile communication device with a back-up device that does not require a connection to a standard computer, such as, for example, the exemplary computer of FIG. 7. For example, when a person with a mobile communication device is traveling away from the office, sometimes it is necessary or desirable to travel without a computing device such as a laptop computer; however, a person may still need to back up the data in his or her mobile communication device.
Often in some settings, such as quality control, mass reprogramming, or incoming materials check, it is necessary to run multiple devices, such as smartphones or tablets, at the same time. Depending on the situation, the batteries of these devices may be mostly or completely exhausted. Because many of the newer devices require upwards of 2 amperes (A) of charge current, often as much as up to 3A, normal hubs or computers can not deliver sufficient power for multiple devices.
Some exemplary embodiments described herein provided for mobile devices to be collected and processed. However, in some cases, the devices being processed may still be locked when the processing begins, and the user is not available to provide unlocking information. In other cases, by the time a mobile device is received and shipped to a centralized processing facility (which can sometimes take weeks), the device may have dropped in value (up to 50 percent per week, in some cases). For example, when a new model of a particular device is released, the value of the old model may drop immediately and precipitously. Thus such a prolonged processing time may create substantial damages to the entity holding the inventory. Accordingly, alternate embodiments of the present disclosure may be incorporated into stores and other locations to receive used mobile devices, perform a variety of tests and analyses on such devices, remove or backup the user's data from the mobile device, and configure the device for resale or reuse by other users.